Thanks for the contribution and for the persistence (3rd attempt!). The concept is valid — buying Stars via Fragment with TON payments is genuinely useful and doesn't duplicate what sdk.telegram already provides.

However, there are critical security issues that block this PR:

Security — must fix

1. Hardcoded API token — fragment_api_token: "paperno" is checked into the public repo (line 88). Default should be "" or null, with sdk.secrets.require("fragment_api_token") for runtime resolution.

2. Plaintext HTTP to unknown server — http://72.56.122.187:8000/api/v1/stars is an unaudited third-party IP with no TLS. The plugin sends the agent's TON wallet address and payment data over cleartext. This is a MITM vector and a fund theft risk. At minimum:

   • The endpoint must be HTTPS
   • The server/service needs to be identified and documented (who runs it? what's the trust model?)
   • Default should be empty string with explicit error, not a hardcoded IP

SDK compliance — must fix

3. Missing scope: "dm-only" on both tools — they trigger TON payments, must be DM-only per project conventions.

4. Missing secrets in manifest — fragment_api_token must be declared in manifest.json so the webui prompts users on install:

   "secrets": {
     "fragment_api_token": { "required": true, "description": "Fragment API token for Stars purchases" }
   }

5. Error anti-pattern — several branches return { success: true, data: { status: "error", message: "..." } }. Errors must always be { success: false, error: "..." }.

Minor

6. Leading space in manifest name: " Telegram Stars Purchase" → "Telegram Stars Purchase"
7. Branch hygiene: please submit from a feature branch, not main

Happy to re-review once the security issues are addressed. The core logic (DB schema, order polling, payment flow) is solid — it just needs a trustworthy and secure transport layer.